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We investigate the notion of orchestrated compliance for client/server interactions in the context of 
session contracts. Devising the notion of orchestrator in such a context makes it possible to have 
orchestrators with unbounded buffering capabilities and at the same time to guarantee any message 
from the client to be eventually delivered by the orchestrator to the server, while preventing the server 
from sending messages which are kept indefinitely inside the orchestrator. The compliance relation 
is shown to be decidable by means of 1) a procedure synthesising the orchestrators, if any, making a 
client compliant with a server, and 2) a procedure for deciding whether an orchestrator behaves in a 
proper way as mentioned before. 

1 Introduction 

Session types and contracts are two formalisms used to study client/server protocols. Session types 
have been introduced in lfl6l as a tool for statically checking safe message exchanges through channels. 
Contracts, on the other hand, as proposed in lfl2l IT8l fl3l . are a subset of CCS without T, that address 
the problem of abstractly describing behavioural properties of systems by means of process algebra. In 
between these two formalisms lie session contract^ \ as introduced in III [3] ;8] |9| ; this is a formalism 
interpreting the session types into a subset of contracts. 

In the theory of contracts, as well as in the formalism of session contracts, the notion of compliance 
plays a central role. A client p is defined as being compliant with a server a (written as p H a) whenever 
all of its requests are satisfied by the server. Now it might be the case that client satisfaction cannot be 
achieved just because of a difference in the order in which the partners exchange information, or because 
one of them provide some extra un-needed information. 

Consider the example of a meteorological data processing system (MDPS) that is permanently con¬ 
nected to a weather station to which it sends, according to its processing needs, particular data requests. 
For the sake of simplicity, we consider just two particular requests, namely for temperature and humid¬ 
ity. After the requests, the MDPS expects to receive the data in the order they were requested. In the 
session-contracts formalism the interface for the simplified MDPS can be stated as follows: 

MDPS = recx. tempReq.humReq.temperature.humidity.* 

(Here, as in CCS, a symbol like ‘a’ stands for on input action, whereas ‘a’ denotes the corresponding 
output). We assume a weather station to be able to send back the asked-for information in the order 
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decided by its sensors, interspersed with information about wind speed: 

WeatherStation = recx. tempReq.humReq. (temper ature. humidity, wind.* 

© 

humidity, temper ature. wind.*) 

With the standard notion of compliance, it is not difficult to check that MDPS / WeatherStation, 
since the client MDPS has no input action for the wind data, and also since it could occur that the 
temperature and humidity data are delivered in a different order than expected by the MDPS. 

A natural solution to this would consist of devising a process that acts as a mediator (here called 
orchestmtor) between the client and the server, coordinating them in a centralised way in order to make 
them compliant. This sort of solution is the one adopted in the practice of web-service interaction, in 
particular for business processes, where the notion of orchestration has been introduced and developed: 

“ Orchestration: Refers to an executable business process that may interact with both internal 
and external web services. Orchestration describes how web services can interact at the 
message level, including the business logic and execution order of the interactions. ” [ 20] 

In the context of the theory of contracts, this solution was formalised and investigated by Padovani |[T9l . 
where orchestrators are processes that cannot affect the internal decisions of the client nor of the server, 
but can affect the way their synchronisation is carried out. 

The orchestrating actions an orchestrator can perform have the following forms: 

(a,a) (resp. (a,a)): the orchestrator gets a from the client (resp. server) and immediately delivers it to 
the server (resp. client) in a synchronous way. 

(a, e) (resp. (e, a)): the orchestrator gets a from the client (resp. server) and stores it in the buffer. 

(a, e) (resp. (e, a}): the orchestrator takes a from the buffer and sends it to the client (resp. server). 

So a possible orchestrator enabling compliance for our example would be 

f = rec*.(tR,tR).(hR,hR).((t,t).(h,h).(e,w).* 

V 

(e,h).(t,t).(h,e).(e,w) .x) 

where tR, hR, t, h, and w stand for tempReq, humReq, temperature, humidity, and wind, respectively. 
The orchestrator f rearranges the order of messages when necessary, and retains the wind information, 
not needed by MDPS. 

Actually, the orchestrator f is not a valid orchestrator in the sense of fl9l : indeed the wind infor¬ 
mation is never delivered to the client (i.e. it is implicitly discarded), so that the buffer corresponding 
to f would be unbounded. Unbounded buffers are not allowed in ||T9l , where boundedness of buffers is 
used to guarantee both decidability and the possibility of synthesising orchestrators. In a session setting 
instead, as is the present one, decidability and orchestrators synthesis can be established even in presence 
of unbounded buffering capabilities of orchestrators. 

In a two-parties session-based interaction, the choice among several continuations always depends on 
just one of the two actors. To let our formalism fully adhere to such a viewpoint our session orchestrators, 
besides (as argued in lfl9l ) being processes that cannot affect the internal decision of the client or the 
server, are such that they do not create any non-determinism besides that already present in the partners. 
This will correspond to restricting the syntax in such a way that orchestrators like, for instance, (e, a) .fj V 
(b, e).f 2 , are not allowed. In fact, in the latter orchestrator, the choice of receiving an input from the client 
or from the server would not depend solely on the partners. The f described above does respect this syntax 
restriction. 
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success 
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Figure 1: The grammar of raw session-contracts 


Moreover, in our system it will be possible to prove that f: MDPS -H Weatherstation i.e.: MDPS 
and Weatherstation manage to be compliant (represented by -H in our context) when their interaction is 
mediated by f. In our system we will also manage to prevent the presence of fake orchestrated complying 
interactions , like that between the client a.b and the server a through the orchestrator (a,a).(b,e). In 
this case the client gets the illusion that all its requests are satisfied, whereas its output b never reaches 
the server, but will be indefinitely kept inside the orchestrator’s buffer. While in the contract setting of 
fl9l such compliant interactions are allowed, in our session context we manage to rule out orchestrators 
behaving like (a,a).(b,e), which never deliver a message from the client to the server. 

We shall prove that properties like the one just mentioned, characterising well-behaved orchestrators, 
are decidable. Given an f, decidability of orchestrated compliance through f will be proved. We will also 
show that, given a client and a server, it is possible to synthesise all the orchestrators that make the client 
and system compliant, if any. 

2 Session contracts and orchestrated compliance 

Session contracts are a restriction of contracts lH8llT3Tl . They are designed to be in one-to-one correspon¬ 
dence to session types jT6l without delegation (in JUE2] a version with delegation was investigated). The 
restriction consists in constraining internal and external choices in a way that limits the non-determinism 
to (internal) output selection. 

Definition 2.1 (Session Contracts), i) Let JV be a countable set of symbols and JV = {n | a € Jlf }. 
The set RSC of raw session contracts is defined by the grammar in Figure [7] where: 

• for external and internal choices, n > 1, and a,- £ ,/F (hence di £ JV) for all 1 < i < n; 

• the variable x is a session-contract variable out of a denumerable set; we consider occurrences 
of x in G bound in recx. G. An occurrence of x in G is free if it is not bound, and we write 
F \{g) for the set of free variables in G. G is said to be closed whenever FV(a) = 0. 

Act = ./F U jV is the set of actions. 

ii) The set SC of session contracts is the subset of closed raw session contracts such that in 
a I . <7 1 H - b a n .G„ and d\ ,G\ © • • • @d n .G n , the a,- and the di are, in both, pairwise distinct; more¬ 

over, in recx. G the expression G is not a variable. 

As usual, we abbreviate a\ ,G\ H- \-a n .G n by £” =1 «(•<£, and d\.G\ ©• • • © d n .G n by ® " =1 dj.Gj. We also 

use the notations £,., /«/.a, and for finite and non-empty I. We take the equi-recursive view of 

recursion, by equating recx. a with a{x/recx. a}. 

The trailing 1 is normally omitted: for example, we will write a + b for a.l + b.l. Session contracts 
will be considered modulo commutativity of internal and external choices. 
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The operational semantics of session contracts is given in terms of a labeled transition system (LTS) 
<7 —t o' where a, o' G SC and a either belongs to a set of actions Act or is an internal action t. 

Definition 2.2 (LTS for Session Contracts). We define the labelled transition system (SC, Act, —>) by 
_ _ t _ _ a 

d\.0\ 0 • • • (B d n . O n —} dk. Ofr d. O —^ O d\ .0\ d n . O n ——y Ok 

where 1 <k <n, and O o' is short for (a, a, a') G —K We shall use —> as shorthand for -4. As 
usual, we write for —>* and ==> for —>* with a € Act. 

Notice that reduction is not defined through contextual rules, so reduction only takes place at the 
‘top’ level. Thereby, it is impossible for recx.a to unfold more than once without consuming a guard 
(remember that a is not a variable): so recursion is contractive in the usual sense. We will safely assume 
that no two consecutive rec binders (as in recx. recy. a) are present in a session contract. 

We observe that => is well defined, in that if a G SC and a =4- o' (or a => a'), then a' G SC. 
Session orchestrators As also done in Ifl9l in the context of the theory of contracts, we intend to 
investigate the notion of compliance when the interaction between a client and a server is mediated by 
an orchestrator. Different from the broad contract setting, the session setting we are in induces some 
natural restrictions to the syntax of orchestrators, making it safe to have orchestrators with unbounded 
buffers. Moreover, it is possible to check whether any output from the client is eventually delivered 
by the orchestrator to the server, as well as whether there might be an infinite interaction which falsely 
progresses because it is made only of outputs from the server to the orchestrator (see Section[4]). 

The set of actions an orchestrator can perform, that we take from ||T9l , have been informally described 
in the introduction^ 

It can be reasonably argued that orchestrators must not show any internal non-determinism. Taking 
into account now the session-based interactions of our setting, such an assumption should be further 
extended, keeping in mind that in a session-based client/server interaction any possible non-determinism 
is due only to the internal non-determinism of the two partners. We therefore define our session- 
orchestrators so as to enforce this point of view. It follows that the only choice we allow in session- 
orchestrators (represented by ‘V’ in expressions like / Mg) is an external one, and it is necessarily driven 
by the internal choice of one of the two partners. This implies that the actions immediately exhibited 
by / and g in an orchestrator like / V g must have the same direction, i.e. must belong to just one of 
the two subsets {(a,e),(a,a) \ a G JV} or {(e,a) | (a,a) \ a G JC}. Besides, orchestration actions of 
the form (a, e) or (e,a) must be used just as prefixes p in orchestrators like p ./. The other ruled-out 
cases, like (c,e).f V ( e,b).g' or (c,e)./' V ( e,b).g ', would conflict with the session viewpoint or, like 
(c,e).f V (b,e).g r , would be meaningless according to the syntax of session contracts. 

We now formally define orchestration actions by partitioning them into different syntactic categories. 

Definition 2.3 (Session-orchestration actions). We define OrchAct as the set of session-orchestration 
actions p described by the following grammar (where a G and a G JY): 

p ::= ti | | o o ::= (a,e) | (e,a) 

li ::= (a,e) \ (a,a) Ir ::= (e,a) | (a,a) 

2 One could wonder whether just asynchronous orchestration actions can be taken into account, since any (a, a) action can 
be safely mimicked by two asynchronous ones, namely {a, £).(£,«) (similarly for (a,a)). A difference in fact would arise only 
for what concerns implementation, since the protocol for a synchronous exchange would not involve the use of a buffer, which 
is instead necessary for asynchronous actions. Such an implementation issue seems unlikely to be related to our theoretical 
treatment. In contrast, we shall point out in Remark l431 how implementation related aspects might affect our formalisation. 
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We let p,p',pi,... range over orchestration actions, and p over both finite sequence /i| ...p n in 
OrchAct* and infinite sequence pi ...p n ... in OrchAct”. 

Definition 2.4 (Session Orchestrators). We define Orch as the set of session orchestrators, ranged over 
by f,g,h, ■ .., described by the closed terms generated by the following grammar: 


fig -= i 

! iL-fi V • • • V i L .f„ (n> 1) 
I iR-fiV---Vi R .f n (n > 1) 

I o.f 
x 

recx.f 


We impose session orchestrators to be contractive, i.e. the f in recx.f is assumed to not be a variable. 

The expression l represents the orchestrator offering no action, o.f offers just the orchestration 
action of the category o and continues as /, whereas i/ . /j V • • • V (/ . /„ and iR.f\ V • • • V Ir-J,, offer n 
(uni-directional) actions of the syntactical categories, respectively, II and Ir. Recursive orchestrators 
can be expressed by means of the rec binder and recursion variables, in the usual way. As for session 
contracts, orchestrators are defined as to have recursion variables guarded by at least one orchestration 
action. In the following we shall often refer to ‘session orchestrators’ as simply ‘orchestrators.’ As for 
session contracts, we take an equi-recursive point of view, so identify recx.f and f{x/recx.f}. 

We now define the operational semantics of orchestrators as an LTS. 

Definition 2.5 (LTS for Orchestrators). We define the labelled transition system (Orch. OrchAct. —>) by 


P-f h— ^ / 


/A/' 

/v*A/' 


g A g' 
fvg A g' 


Given a sequence JU, we write f A whenever f A> f\ A» • • • A» fi, if p = p\ ■ • ■ p n £ OrchAct*, or 
f A> • • • A). f n i - n+ - 1 »• • • ifp = p\ - ■ ■ p n - ■ ■ £ OrchAct”. We write f rfy if there is no p such that f A. 
Definition 2.6 (Orchestrator Traces). Let f £ Orch. 

1. The set Tr(/) C (OrchAct* U OrchAct”) of traces of / is defined by: Tr(/) = { fi \ f A }. 

2. The set MaxTr(/) C (OrchAct* U OrchAct”) of maximal traces of / is defined by 


MaxTr(/) = {jU € Tr(/) | 3/' [/ A f rfr ] or p £ OrchAct” } 


As in lfl9l . we define an orchestrated system as a triple (p,/, a) (written p ||y a) representing p (the 
client) and a (the server) interacting with each other under the supervision of /. 

Definition 2.7 (Orchestrated Systems operational semantics). The operational semantics of orchestrated 
systems is defined as follows: 


a a 


PlI/tf-AII/tf 


P WfO-^P\\fO' 


f 


(a,a) 


>/' <7 


a 

p ->p 




ii (“>“} / ii / 

P 11/cr- >P WfO 


ii <“’ £ > / ii 

P II- >P \\f<s 


(e,a) a , 

f 1 ->• / O -> <? 

II ( £ ’“> II / 

P II fO - >p\\fO' 


We write => for —>* o A o —>*, nnr/ =A> yhr =A o ■ • ■ o =A> =A> o =A o ■ • •) if p is finite 

(resp. infinite). The notation p ||/ a —fiv will be used when both p \\ f O —f-y (according to the first two 


rules above) and -> 3p [p ||p <7 


hold. 
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Notice that for the operational semantics of orchestrated systems we have defined labelled reductions 
instead of a reduction relation (as done in We label orchestrated-systems’ transitions by the orches¬ 
tration actions which make them possible, since in our setting we need to check for particular conditions 
of orchestrator buffers after the evolution of an orchestrated system. A buffer can be explicitly coupled 
with an orchestrator or can be represented implicitly by the actions performed by the orchestrator. The 
latter is the choice of lfl9l . that we maintain. 

We now define a notion of compliance which is coarser than expected because of possible unfair 
behaviour of the orchestrators, which will be refined in Section 0] 

Definition 2.8 (Disrespectful and Strict Orchestrated Compliance). An orchestrator f is said to be p-o 
strict whenever, for any finite jU, f implies p 11 / c ==- . We define: 

i) f: p -H* <7 iff is p-o strict, and for any jU, p' and o', the following holds: 

p ||/a ==> p' ||/' o' —fy implies p' = 1. 

Wp-Vfo if 3/[/:p-H*<y]. 

3 Orchestrators Synthesis 

In this section we define an inference system [H nf for (possibly open) orchestrators, deducing judgments 
like / : p H* c, under finitely many assumptions of a certain shape. We first establish that the system 
is sound with respect to the -H* relation. Then, on the basis of that system, we provide an algorithm 
Synth for orchestrator synthesis which, given p and o, returns the set of all the relevant orchestrators / 
such that [H nf / : p H* c (namely with T = W) and hence that / : p -H* o. The algorithm is essentially an 
exhaustive proof search for [H nf that can be shown to be always terminating. 

Definition 3.1 (The orchestrators inference system cT nf ). The judgements of the system are expressions 
of the form l [P nl f : pH* a, where p,o € SC, f is a (possibly open ) orchestrator and T is a set of 
assumptions of the form x : p, H* c, such that: x:p H* o £ T & y:p H* o € T =>- x = y (so 1' represents 
an injective mapping from variables to expressions of the form p H ct O ). The axioms and rules of the 
system are described in Figure \2\ 

In the inference system of Figure [2]the symbol H* is a relation symbol representing the relation -H* as 
defined in Definition l2.8l In order to give the intuition behind the inference system, let us briefly comment 
on one of the rules, say (cplE-l). In case it is possible to show that f is an orchestrator for f p -\f o, 
orchestrated compliance can be obtained for £/ 6 /«,.p, _ H tti O' by means of (a p ,e).f', since the (a p ,e) 
action satisfies one of the input requests a,s. In case x f fn(f'), we get that rec x.(a p ,e).f' = (a p ,e).f. 
This means that axiom (ax) has been used in the derivation of f and the interaction between i a i-Pi 
and o finitely succeeds if the actions described in the branch from (cpl£-l) to (ax) are performed. In 
case x € fn(f'), rule (hyp) has been used for f, and a successful infinite interaction is possible between 
Yjiei a i-Pi ar| d o when the orchestrator repeatedly performs the actions in the branch from (cpl£-l) to 
(hyp), as described by the recursive orchestrator rec x.(a p ,e).f. 

Definition 3.2 (Judgment Semantics). Let T = [x\ :pi H* ci,... ,xppi< H* a* }, and 6 be a map such that 
6(xi ) = f b where the f\s are proper (i.e. closed) orchestrators. Then we define: 

o |= T ^ V(x ( : P ; H* Ci) er[0 (Xi) : Pi a, ] 

T |= / : p H*a 4 V 0 [6 \= T => 9(f) : p ^*a] 

where 9(f) is the result of substituting, for all variables x G f, all free occurrences ofx by 6 (x). 
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(ax) : 
(cpl£-l) : 

(cpl0-r) : 

(cpl0-l) : 

(cpl©.£) : 
where 

(cpl£.©) : 
where 


T 0 f 1 : 1H* a (hyp). r,x:p 0(7 0 f x : p 0C7 

r, x: I, e/ cii.pi 0 a [0 f : p p 0 a T, x:p 0 L, €/ a,. <7, 0 f : p 0 a p 

- - - : — i pel) (cple-r) : ----- — 

r 0 rec x.(a p ,e).f : £, e/ a ; -.pH o T l>i nf rec x.{e,a p ).f : p~\' Ziei a i- a i 


r, x:(& ieI aj.pi^ k (Bj e jbj.Oj 0/ ; - : ©; g /fl;-P;0 Qj (V/ £ J) 

T 0 rec x.\/ jeJ { e , bj).fj : © ie/ a,-.pi0 ® je jbj.Oi 

r, x: ®,-g/ Oj-pj 0 ® jeJ bj.a, 0 f : p, 0 © jeJ bj. <r f (Vi <S /) 
r 0 recx. Vie/ (a, ,e)-fi ■ ©,- €/ a i-Pi 0 ffi/ei & j • 0 

r'^ fr.pi^'Ljejaj.Oj (Vi etf) r'0/,:p,0cT,- (Vi eg) 
r 0 rec x.{\J heH {a h ,e).f h ) V ( \J keK { a k,a k ).f k ) : ©, € /<FpH‘*E 7e 70 CT / 
r = F, x: ©ig/fl/.pi H D/ei a j ■ 0 ■ 

h' :> rl ,/) : I,-, /</,.p, -0, (V0//) F'0/ /: p ; 0, (V/€*) 

F > recx .(\/ heH (E,ah) -fh) \/ (^/kf_K( a k-, a k)-fk) - ^Liei a i-Pi^ ©/ey a y© 
r = r, x. Y*i&i a i-Pi~\ ©/ej©’•© 




(J = H\JK,K CI) 


Figure 2: The inference system 0. 


(pe/) 


Theorem 3.3 (Soundness). If T 0 / : p 0 a 0/2 r |= / : p 0 <7. 

Proof. (Sketch) It is possible to device a sound and complete system [> for judgments of the shape F \> 
f : p 0 a, where / is a closed orchestrator and where T is a set of assumptions on closed orchestrators 
(not on variables as in 0). Now it can be proved that if / is closed and F 0 / : p 0 a is derivable, 
then for any 6 such that 6 |= T we have 0(r) t> / : p 0 a, where 0(r) is the result of substituting all 
orchestrator variables x by 6(x). Then the thesis follows from the soundness of [>. □ 

The synthesis algorithm Synth is defined in Figure [3] Given a set of assumptions F, a client p and 
a server a, the algorithm computes a set of orchestrators 0 such that for all / £ 0 a derivation of 
F 0 / : p 0 (7 exists. The algorithm essentially mimics the rules of the inference system of Figure [2] 
Intuitively, in case we are looking for orchestrators for p = 0 /e/ Z//.p/ and a = ® 7&/ a j .a, under the 
assumptions 1, we notice that they can be inferred for such p and a in system 0 only by means of 
rules (cpl0-r) or (cpl©-l) and that their form is, respectively, recx. \f iGl (ai,e).fj or recx. \Jj eJ (£.aj).fj, 
where the /,s and the fjs are the orchestrators for the pairs pi. a and p,oj, respectively. This accounts for 
the fourth clause in the synthesis algorithm. We can prove the algorithm to be sound. 

Lemma 3.4. If Synth(r, p, a) = 0 f 0 then, for all / € 0 F 0 /: p H* a is derivable. 

On the other hand, the algorithm is complete in the following sense: 

Lemma 3.5. If f : p -0 a and Synth(0, p, a) terminates then there exists g such that g £ Synth(0,p,a). 

The g of the above lemma represents f. In particular it could be got by delaying the termination of the 
algorithm when the first clause is applicable. Moreover, it could be got out of / by replacing syncronous 
actions by pairs of asyncronous ones (or also by simply adding asyncronous actions). For instance, for 
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Synth(r,p,a) = 

if x: pH*<7 G T then {x} 
else if p = 1 then { i } 

else if p = Y.iei a i-Pi and (7 = 'L J cj a j- (J j then 
let r' = r, x:p H* a in 

U 6 /{recx. (a,■,£)./ | / G Synth (r',p,, o )} U U/ 6 /{ recx.(e,aj).f | / G Synth (T',p,Oj)} 

else if p = ©, e/ a,.p,- and <7 = ® /G/ aj. <7, then 
let r' = r, x:p H* a in 

{ recx.\J ieI (ai,e).fi \ f G Synth (r',p,, c) } U { recx. V jej( £ Pj)-fj \ fj G Synth (T',p, cj ; )} 

else if p = ©, G /a,.p, and <7 = L /( -v a /- f7 / then 
let r' = r, x:p H* <7 in 

{ recx. (V/ ieff {a h ,e).f h ) V (V keK(ak,a k )-fk) 

\I = HL)K,K CJJ h £ Synth(r',p h ,o),f k £ Synth (T',p kl o k )} 
u U;£/{ recx.(e,aj).f \ f G Synth (r',p, o>} 

else if p = 'Liri a ,.p, and <7 = ®- 6/ a 7 '.0) then 
let r' = r, x:p H* a in 

{ recx.(\/ heH (e 1 ah).fh) V {\l keK ^k,a k ).f k ) 

\J = HUK,K CI,f h £ Synth ( (r' , p, o h ) , f k G Synth (T', p k , o k )} 
u U/£/{ recx. («,-,£)./ I / G Synth (rHp„ o) } 

else 0 


Figure 3: The algorithm Synth. 


p = recx.a.x and a = recx.a.x the orchestrator / = (a,e).(e,a).recx.(a,a).x correctly mediates between 
p and a, the algorithm terminates, but / ^ Synth(0,p, a). On the other hand, g = recx.(a,a).x belongs 
to Synth(0,p, a) and it is related to / in the sense above. It can be shown, besides, that if / is respectful 
in the sense of Sect. [4]below, there exists a respectful g in Synth(0.p. (7). 

It remains to show that Synth is terminating: 

Lemma 3.6. For all T, p and a, the execution of Synth (T, p, a) terminates. 

Proof. (Sketch) The proof is based on the fact that all session contracts in the recursive calls of Synth 
are a sub-expression of either p or a or of a session contract in a judgment in T (which is finite). Since 
session contracts are regular trees, their sub-expressions are a finite set, so that the test x:pH*a G T 
(where x is any variable) at the beginning of Synth cannot fail infinitely many times. □ 

Corollary 3.7. The relation -H* is decidable; moreover if p -H* <7 then it is possible to compute a set -F 
of orchestrators for p and <7 

Recall that the computed orchestrators represent all the possible orchestrators, in the sense of the 
discussion after Lemma [331 

4 Respectfulness 

The definition of orchestrators implies they have buffering capabilities. The sort of buffer taken into 
account in im, as well as by us, is made of a number of bi-directional buffers (where only a finite 
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subset is actually non empty), one for each possible name. A bi-directional buffer is actually made of 
two distinct buffers, one containing the messages received from the client that have to be delivered to the 
server, and the other one containing the messages received from the server that should be delivered to the 
client. 

In lfl9l orchestrators are restricted to have bounded buffering capabilities and such a restriction is 
used in the proofs of several properties concerning contract orchestrators. In our setting we can eliminate 
that restriction, so allowing more client/server pairs to be compliant, like for instance recx.a.x and 
r ecx.b.d.x, and the example in the introduction. We will now formalise the notion of buffer. 


Definition 4.1 (Buffers). 1. A bi-directional buffer B is a set of the form { c “a Sa \ a G jVf where, 
for any a € JV, c a , s a G Z. The c a in c “ arepresents the number of a’s in the part of the buffer 
containing messages sent by the client to the sewer. The s a in c “arepresents the number ofa’s in 
the part of the buffer containing messages sent by the server to the client. 

2. We define: 0 = { °a° j a G JT } and 

L+B = (B \{ c “a s “ }) U { Ca+1 a' ?a } B+J = (B \ { c °a s “ }) U { c °a s ° +l } 

[“B = (B\{ e °a‘ Sa })U{ c “ _1 a' Sa } B a J = (B\ { Ca a s “}) U { Ca a Sa ~ l } 

3. We denote by |B| a the number of a’s in the ser\’er-to-client part of the buffer, i.e. |B| a = s a and 
similarly for the client-to-server part, i.e. a |B| = c a . 


4. The state of a buffer B after an orchestration action p will be denoted by BjU, defined by 


B(a,e) = [ fl B 
B(a,e) = [a® 


B(a,a) 


B(e,a) = B fl J 
B(e,a) = B+J 


5. By B/i we denote the buffer B after the sequence JU of orchestration actions. 

In Definition 12.81 we considered the relation -H*, which we have studied so far. This is however 
much weaker than expected, and it is time to face the issue. Consider the simple orchestrated system 

d.b W/a.c.d where / = {a,a).(b,e).i. 

It is easy to check that / : d.b-W* a.c.d since / is strict for the given client/server pair and 
d.b || fa.c.d =^> 1 \\i_c.d -f-t , where p = ( a,d)(b,e ). It is definitely true that all the client’s “requests” 
have been satisfied, but not all by the server! The action b of the client has been taken care of exclusively 
by the orchestrator, which in that case has not acted simply as a mediator, but has effectively participated 
to the completion of the client’s requests. 

So, in order to strengthen Definition l2.8l (Hl). in case p'\\f o' —f-y , we have to impose some conditions 
on the client-to-server buffer associated to /'; in particular, that it should be empty. Of course, a similar 
condition must hold also for infinite interactions; this implies that in an infinite interaction, for any 
possible name, say a, used by the orchestrator, the latter cannot indefinitely perform input actions for 
a from the client (even if interspersed with actions for other names) without ever delivering an a to 
the server. We must therefore forbid a client like r ecx.d.c.x to be compliant with the server recx.c.x by 
means of the orchestrator r ecx.(a,e).(c,c).x. Orchestrated finite and infinite interaction sequences which 
do not correspond to unwanted situations like those just sketched will be called client-respectful. 

Even if the notion of compliance enforces the sense of the bias towards the client (any client request 
must be eventually satisfied by the server), some conditions need to be imposed on the part of interactions 
on behalf of the server. In fact, we wish to prevent a server to be compliant with a client by means of an 
orchestrator that, from a certain moment on, interacts infinitely many times with the server only, like in 
the orchestrated system 



30 


Orchestrated Session Compliance 


d.b ||/ r ecx.c.b.x where / = (a,e).recx.(e,c).{e,b) jc 
We wish to prevent this kind of infinite interaction that we dub definitely server-inputted. Notice that, 
however, we can permit interactions in which the orchestrator can perform the input of some a from the 
server infinitely many times, without ever performing an output of a to the client, like it happens for 
wind in the example in the introduction. 

We observe that the problem - whether an orchestrator will ever engage in any of the aforementioned 
pathological interactions - might well be undecidable for contracts in general; indeed, it shares similari¬ 
ties with, for example, termination of two-counter machines 11X71 . However, we stress that we are in the 
restricted setting of session contracts, which suffices to make such properties decidable. 

Among the properties we have to take care of, one is that in an interaction sequence there cannot exist 
an orchestrator action removing an element from an empty buffer, i.e. a sound sequence never sends an 
element a to a server or to a client if the a has not been previously received. We call the sum of all the 
above properties respectfulness. 

Definition 4.2. Given JU £ OrchAct* U OrchAct 00 , we define a JjU, its left-restriction to a name a, as 
follows (X is the empty sequence): 

a \X = X, 

a\(pn') = Halt', if lie {(e,a), (a,e)}, 

J(MM') = otherwise. 

Definition 4.3 (Respectful sequences and orchestrators). Let jU £ OrchAct* U OrchAct” and p £ OrchAct. 

a) Given S C OrchAct, we say JU to be definitcly-.S’ whenever: 

3k Mm > k [the m-th element of JU belongs to S\, 

For sets that are singletons we write ‘definitely-pt ’ instead of ‘definitely-{p }.’ 

b) We say JU to be a sound sequence whenever: 

Ma £ jV Mn < |ju| [ a |0jUi ■■■ p n | >0 and |0pi ■■■ p„ | a > 0] 

c) We say JU to be client-respectful sequence whenever, for any a £ ,//: 

„j jU is finite and a | 0jU | = 0 or a \ p is infinite and non-definitely- (a,e) 

d) We say JU to be non-definitely server-inputted whenever: 

jU is infinite =$> JU is non-definitely -{ (e,a) | a £ ,W } 

e) We say JU to be respectful whenever }U is sound, client-respectful and non-definitely server-inputted. 

f) We say that an orchestrator f is respectful whenever every JU £ MaxTr(/) is so. 

We will look now at a few examples in order to get a better intuition about the above definition. 
Example 4.4. • The finite sequence (a,e).{e,b).(e,a) is not respectfid since it is not sound. In fact, 

for the name b, we have that | 0. (a, e). (b, e) | b = — 1 < 0. 

• The sequence (a,e).(b,e).(e,d) instead, is sound, but nonetheless it is not client-respectful, since 

it is not infinite and for the name b we have fc|0(a,e).(fc,e).(e,a) | = 1 0. 

• The orchestrator f = ( c,c).recxf(a,a ) V (c,e).{b,b).x) is not respectful since it is not client- 
respectful. In fact, for the sequence jU = (c,c).(c,e).{b,b).(c,e).(b,b) • • • £ MaxTr(/) and the name 
c, we have that c Jju is infinite and c JjU = (c,e).(c,e).(c,e) ■■■ is definitely-(c,e). In fact, from the 
very first elemen t on it is made of (c, e) actions. 


Barbanera, van Bakel, de’Liguoro 


31 


• The orchestrcitor f = (c,c) .recx.((a,a) V (e,b).(e,c).x) is not respectful since it is not definitely 
server-inputted. In fact, the infinite sequence fi = (c,c).(e,b).(e,c).(e,b).(e,c) ■ ■ ■ G MaxTr(/) 
is definitely-{(e,a) \ a G Jtf }. The orchestrator f in the introduction, instead, is non-definitely 
server-inputted, and also respectful, as a matter of fact. 

Remark 4.5. By Definition 14.21 the sequence fi in Definition 14. JlfrD cannot contain synchronous or¬ 
chestration actions like (a,a). Hence, for example, the orchestrator g = (a,e).tecx.(a,a).x is not client- 
respectful, and so it is not respectfid at all. This is because the first a coming from the client will never 
be delivered to the server since any subsequent output a will be paired with a further input of a. This 
might be irrelevant when distinct occurrences of the same message are indistinguishable, but in general 
the number of input-output actions matters. 

On the other hand forcing the orchestrator to immediately forward a message is a desirable capabil¬ 
ity, which would be definitely lost by equating (a,e).(e,d) to (a,a), and by ruling out the latter. 

We can now properly define the full notion of compliance and characterise it. 

Definition 4.6 (Orchestrated Session Compliance), i) We say that a client p is compliant with a server 

c through the orchestration of f, and denote this by f : p ~W c, whenever 

a) p ||/ C == p' 11 j'i o' —f-7 implies p' = 1 and JLi is respectful, and 

b) p ||/ <7 =^4 with ju G OrchAct 00 implies p is respectful. 

ii) We write p -H <7 whenever there exists an orchestrator f such that f : p ~W a. 

Notice that we cannot define orchestrated compliance by simply imposing / to be respectful in 
Def. M . since that would prevent the possibility of a be compliant with a through the mediation 
of the orchestrator (a,a) V (e,b). This orchestrator is not respectful, but its sequences of actions in any 
possible orchestration between a and a are respectful. 

We can show that, if compliance could be obtained by means of a non-respectful orchestrator, it is 
always possible to get it through a respectful one. Besides, we can show the correspondence between -H 
and -H*. 

Proposition 4.7. i) f : p HI c =4 3f [f : p -H c such that f is p-c strict]. 

ii) f : p -H <7 and f is p-c strict 44 f : p -H* c and f is respectful. 

iii) p -Wo 44 3/ [/ : p -H* c where f is respectful}. 

In order to show decidability, we provide a characterisation of respectfulness based on the notion of 
buffer-aware trees and its related labelings below. 

Definition 4.8 (Buffer-aware trees of /). a) Let a G jV. We define the buffer-aware a-tree of an orches¬ 
trator f, denoted by cfs a (f), as the tree defined by induction in Figure [7] The edges of the tree have a 
left- and a right-weight denoting, respectively, the increment of the client-to-ser\’er and of the serve r- 
to-client buffer for the name ‘a ’ caused by the orchestration actions performed by f. 

Given an edge e of a buffer-aware a-tree t, we denote is left (resp. right) weight by lw' (e) (resp. rw' (e)). 

b) We define the buffer-aware *-tree of an orchestrator f, denoted by cTs* (/), as the tree with the 
same nodes and edges as any els“(/)» but such that the left (resp. right) weight of an edge e is 
lw cTs " ( /) (e) (resp. rw cTs “ V\e) ). 

Note that the left and right weights of the edges of a buffer-aware *-tree of an orchestrator / are 
either 0, — 1, or +1. 
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Figure 4: Buffer-aware a-tree 


Definition 4.9 (Buffer-labelling of cTs"(/')). We define the buffer-labelling of cTs"(/) by labelling its 
nodes with left and right labels as follows: given a node N and the path P in cTs" (/) from the root to N, 
we left-label N with the sum of all the left-weights of the edges in P, whereas we right-label N with the 
sum of all the right-weights of the edges in P. 

We now provide characterisations for the properties defining respectfulness. 

Definition 4.10 (Sound buffer-labelling). The buffer-labelling o/cTs a (/) is sound whenever 

a) there is no negative left-label and no negative right-label and 

b) for any leaf x and corresponding recx. node, if k is the left (resp. right) label of x and h is the left 
(resp. right) label of recx., then: k — h >0. 

Proposition 4.11. / is sound W for any a € JV, the buffer-labelling of cTs" (/) is sound. 

Proof. (<^=) By the labelling, it is impossible to get a non-client-respectful sequence out of /. 

(=^) By contraposition; assume that for a name b £ JY, the buffer-labelling of cTs h (f) be unsound. Then 
we have two cases to consider: 

(a) There is a negative label. We then get immediately an unsound sequence. 

(b) There exists a leaf x and its corresponding recx. node, where k is the left(or right-)-label of x and h 
is the left-(or right-)label of recx., s.t. k — h < 0. It is immediate to get an unsound sequence. D 

We say that a node gets to l whenever its subtree contains a l node. 

Definition 4.12 (Client-respectful buffer-labelling). The buffer-labelling of cTs" i f ) is client-respectful 
whenever 

a) any l node is left-labelled with 0; 

b) for any leafx and corresponding node of its binder recx., ifk is the left-label ofx and h is the left-label 
of recx., then 
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1) if the recx. node gets to 1 , then h = k; 

2) otherwise, if all the left-labels of the edges from x to recx. are 0 then h = 0; 

c) for any path from a leaf x to its corresponding recx. node, either no edge is right-weighted with +1 

or there is at least an edge with right-weight — 1. 

Proposition 4.13. 

f is client-respectful <=> for any a G ,./V, the buffer-labelling of els' 7 (/) is client-respectfid. 

Proof. (s=) By the labeling rule it is impossible to get a non client-respectful sequence out of /. For 
finite sequences this impossibility is guaranteed by clauses © and (Jb]) of Definition 14.121 for infinite 
ones by clause ©. 

(=^) By contraposition; assume that for a name b G jV, the buffer-labelling of cTs b (f) be non-client- 
respectful. We consider the four possible cases: 

1. A label of a l leaf is not 0. In that case we immediately get a finite sequence out of / which is 
non-client-respectful. 

2. There is a node * labelled with k and its corresponding node recx. gets to l and it is labelled with 
h, with k f h. Then the sequence out of / corresponding to going to recx., then from node recx. 
to x a non negative number of times n and finally to the l node cannot be client-respectful, since 
at the end the client-to-server buffer for b would have n * (h — k) elements in it. 

3. There is a node x labelled with k, its corresponding node recx. does not get to l, all the left-labels 

of the edges from x to recx. are 0 and h = 0. In that case the trace p corresponding to the infinite 
path starting from the root and then keeping indefinitely on passing through recx. and x is such 
that b\p is finite and |0(^J /X) | 0. 

4. there exists a path from a leaf x to its corresponding recx. such that there are some right-weighted 

edges right-weighted with +1 and no edge with right-weight —1. Then it is immediate to get 
an infinite definitely server-inputted sequence out of / which is definitely-^,e) and hence not 
client-respectful. j-| 

Definition 4.14 (Non definitely server-inputted *-tree). Given an orchestrator f, its *-tree cTs*(/) is 
non-definitely server-inputted whenever, for any path from a leaf x to its corresponding recx. node, 
either no edge is right-weighted with +1 or there is at least an edge with right-weight —1. 

Proposition 4.15. f is not definitely server-inputted els*(/) is non-definitely server-inputted. 

Proof. (<t=) By the labelling it is impossible to get a definitely server-inputted sequence out of /. 

(=>) By contraposition; assume that cTs*(/) be definitely server-inputted. So there exists a path from a 
leaf x to its corresponding recx. such that there are some right-weighted edges right-weighted with +1 
and no edge with right-weight — 1. Then it is immediate to get a definitely server-inputted sequence out 
off. ^ □ 

Theorem 4.16. Orchestrator respectfidness is decidable. 

From the above result and from decidability of -H* ( Corollary 13.71 ) we can get decidability of -H. The 
algorithm to decide whether p -H o will first compute .'P = Synth(0,p,a); then if & 0 it suffices to 

check whether there is a strict and respectful / G which is a decidable problem by the above. 

Theorem 4.17. Given p and <7, it is decidable whether p 4(1. 
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We conclude by observing that in lfT9il the lack of unbounded buffering capabilities prevents or- 
chestrators to be used to ensure client compliance with a server that might send an unbounded number 
of unnecessary outputs. To let such sort of interaction possible, in tf2l the notion of skp-compliance 
(dubbed -T kp ) was investigated for session contracts, where a client is compliant with a server whenever 
all its requests can be satisfied thanks to the possibility of discarding a (possibly unbounded) number 
of unnecessary server outputs. Interactions of this sort can actually be earned out by means of our ses¬ 
sion orchestrators, since it is possible to prove that p H skp G implies p -H* a. In the example in the 
introduction, in fact, the wind information is unbounded and “discarded” by the orchestrator. 


5 Related and future work 

The notion of compliance naturally induces a substitutability relation on servers that may be used for 
implementing contract-based query engines (see IT9l for a detailed discussion). Hence it seems worth¬ 
while to investigate the session sub-contract relation induced by our orchestrated compliance on session 
contracts. Whereas server substitutability is at the core of the results in fl9l . we deem it relevant to 
investigate also client substitutability, in the style of what was done in 010 for session contract and in 
ifTOll for the more general notion of contract. 

An approach to the formal description of service contracts in terms of automata has been recently 
developed in @. The notion of contract automaton is related to that of contract as well as of session 
contract. Besides, the notion of contract agreement in |6l somewhat resembles that of compliance. In 
the framework of that paper, orchestrators are synthesised to enforce contract composition to adhere to 
the requirements for contract agreement. Even if the authors of J6l work on the overall satisfaction in 
a multiparty composition of principals, it is definitely worthwhile, as a future investigation, to study 
the relation between the notion of orchestration, as developed in lfl9l and in the present paper, and the 
approach of @, which in turn has been related in 0 to the model of choreography of communicating 
finite state machines (CFMS) fllTl . For what concerns session contracts in particular, the investigation 
of the correspondence with the above mentioned formalisms could start from the result concerning the 
correspondence of binary session types with a particular two-communicating-machines subclass (see 
lfl5l for references). Such a correspondence between session types and communicating machines has 
been pushed further to the multiparty setting in |[T5ll . 

Many properties of the model of CFSM which are untractable ceases to be so when Bags, instead 
of - or together with - FIFO queues are taken into account |[T4l . The similarity of contracts and session 
contracts with the CFSM model suggests to investigate the use of bags for session-contract interactions 
to reduce decidability problems in our context to problems in the CFSM model with bags. What does a 
bag correspond to in our context is however not immediate to device. In fact, by putting a bag in between 
d.b and a + b would result in a number of possible non-deterministic evolutions of the system: as soon 
as a is in the bag, it could be used as input for the server; or, in case both a and b get into the bag, the 
server could non-deterministically choose amongst them; etc. Such a behaviour of the system, however, 
goes far beyond the session setting we are in, where non-determinism is restricted to occur only inside 
the client and server. 

Session contracts have been also investigated in papers like 0(21 where, overloading the name, they 
also have been dubbed session types. In 0 the authors establish a relation between session contracts 
and a model based on game-theoretic notions, showing that compliance corresponds to the existence of 
particular winning strategies. It should be interesting to investigate the meaning and role of the notion of 
orchestration in such a game-theoretical setting. 
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